IBIS Macromodel Task Group Meeting date: 08 July 2014 Members (asterisk for those attending): Agilent: * Fangyi Rao Radek Biernacki Altera: * David Banas ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai Cadence Design Systems: * Ambrish Varma Brad Brim * Kumar Keshavan Ken Willis Ericsson: Anders Ekholm Intel: * Michael Mirmak Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz * Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow * Bob Ross The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Mike L: Arpad is not here, who can chair? - Michael M agreed to chair. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad formulate a vote for next week. - Arpad not present. ------------- New Discussion: BIRD 147: - Michael M: Did we discuss the announcement from SiSoft in the last meeting? - John: Yes. - John: Arpad formulated the list of questions for us in agenda item #5. - Michael M: We can discuss those questions. - Bob: we need to tighten up the list. Question #a) Should we make a recommendation to the IBIS Open Forum about BIRD 147 now (to be accepted as is) and develop a more general solution later? - Kumar: No EDA tool can do optimization. - We should not waste time on this. - Arpad: BIRD 147 addresses the backchannel mechanism only. - It is a subset of a general solution. - Cadence believes it is all that is needed. - Kumar: EDA tools have no place in optimization. - The RX will find a solution and the EDA tool can't interfere. - Arpad: Is it the job of IBIS to cover this or are tools on their own? - Ambrish: The question is what are we trying to solve? - Todd: One of our customers wants this, they optimize on a per channel basis. - SiSoft might have to disengage from this meeting if we can't discuss a solution for that. - Kumar: They can come up with a solution but it will not be what the RX actually does. - Michael M: The EDA tool will have to be involved in any communication between TX and RX. - We have internal tools that find the best settings for a channel. - These tools do make recommendations about what the silicon does automatically. - Todd: ... Whether the hardware does optimization or not. - Michael M: True. - It must be clear to the tool and user what mode you are operating in. - Todd: The silicon doesn't interact with the EDA tool. - The goal is to identify optimized register settings for bring-up. - Michael M: A specific solution and a more general solution would be fine. - Ambrish: Is it the specification's place to define this? - Michael M: We will provide only the pipes. - If vendors want to provide extra capabilities they will need this. - Todd: No one suggested we were putting optimization in EDA tools. - We are generalizing communication between TX and RX. - Ambrish: We saw a TX that makes jitter adjustments without changing taps. - The RX sends analog feedback, just good/bad signals. - Todd: The RX sends info that is not a tap setting? - We need to know the details. - Ambrish: We just need to keep the door open for new methods. - BIRD 147 is formatted for that. - Todd: You're saying you can more broadly enable cross vendor optimization. - This is because BIRD 147 makes no assumptions about what the TX and RX will ccommunicate. - SiSoft is saying the TX can be characterized by taps, spacing, limits, and tap quantization. - If we accept that, legacy TX models can work with optimizing RX models. - BIRD 147 requires both TX and RX to be written to support optimization. - Ambrish: BIRD 147 helps vendors A and B to agree on what the controls are. - Kumar: We are not talking about vendor A and B. - We can't be restricted from doing proprietary things. - What goes to the TX can't be done outside the RX. - Michael M: We don't want the TX and RX stepping on each other. - Arpad: How involved does the spec have to be? - Walter: There are two kinds of models in this context: - One has limits on granularity, it does standard things. - Another has a "framis" knob that can be anything. - The RX might know how to handle the TX's framis. - It should be a requirement for the RX to be able to communicate those settings. - Todd: The Cadence proposal is based on the BCI file. - The SiSoft proposal would not know how to handle new control types. - Walter: A new "framis" parameter could be added to tell the tool what settings to change. - Todd: The question has been if we put parameters to be tweaked in the spec or just say "hers is a channel" and stand back. - The appeal of the SiSoft proposal is co-optimizing TXs not made for it. - Introducing "framis" makes this more a subject of contention. - Walter: We can kill two birds with one stone. - John: An adapter could be used to make existing models work. - Could the SiSoft proposal work in the context of BIRD 147? - The RX would say what it needs to control, the TX would say how to do it. - Walter: A PCIe3 RX would say what it is controlling and the EDA tool would take care of it. - Todd: Careful, this is handled in real time. - Walter: AMI_Init can be called multiple time for legacy models, to adjust settings. - John: Maybe Cadence and SiSoft could merge these ideas - You would have to observe some principles. - Michael M: Maybe this would answer Arpad's first 4 questions. - Ambrish: Is the question how to make model A work with model B in the back-channel framework? - Kumar: The final solution is path-dependent. - Algorithms have vast dynamic range. - It is heavily device dependent. - For example it might change the CTLE first then DFE, or other way around. - Todd: This is the local minima/maxima problem. - Michael M: The tool does not control the order of evaluation. - Kumar: The RX does. - Todd: The question is if we can characterize TX capabilities in a generic way or if specific TX/RX pairs have to be made. - Michael M: We probably are not near agreement on item #e. - Will we have text for a vote next week? - Todd: I think we are closer. - Arpad: Users keep trying tap settings until they like what they see. - Why can't we automate that? - Ambrish: We already have that ability. - Walter: Users have documents to help them do that. - The EDA tool needs that extra information in a format it understands. Questions we did not get to: #b) Should we develop a complete optimization solution and bring that to the IBIS Open Forum when done (with or without BIRD 147)? #c) Should BIRD 147 be extended towards a complete solution? #d) Should we develop an independent BIRD for a general optimization solution (but making sure it works together with BIRD 147)? #e) What should be the scope of the complete solution? - define a system optimization in which the Rx model is in control: in this case the EDA tool would only act as a translator between and optimizing Rx model and a non-optimizing Tx model - define a system optimization in which the EDA tool is in control: in this case the EDA tool would do the optimization with non-optimizing Tx and non-optimizing Rx models ------------- Next meeting: 15 Jul 2014 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives